plan2

Do you have a microservice contingency plan?

How many APIs does your company consume? How many microservices do you depend on? This brave new world of public APIs and microservices is great, but what happens when it’s not?

What happens when a service raises their prices, changes their metering, dies (bankruptcy, acquisition, sunset), pivots, experiences a major outage, or any number of problems facing modern technology companies? These are cross-team problems affecting ops, engineering, and business teams. How will each handle the problem?

Think about how your company consumes these APIs and plan for the worst.

There is no one right answer, but here are some things that should be explored when considering a microservice:

  • Do they offer an open-source version that you could have ready to go if necessary?
  • Will they place code in escrow in the event that they go under? You have a better chance at making this work if you’re a big player, but it’s worth bringing up.
  • How interoperable are they with the competition? Think Amazon vs Rackspace. Switching from one to another isn’t exactly fun, but it is possible to migrate without breaking much.
  • Have plans in place to “roll your own”. Writing code for this might be taking it too far (that’s the reason you’re consuming someone else’s API, right?), but at least have an idea of how you could accomplish the same features with your in-house team and a rough timeline.

So do you have a contingency plan? We’d love to hear your stories (good, bad, or otherwise) on the topic!